A data processing apparatus will typically include one or more devices, for example a central processing unit (CPU), a Direct Memory Access (DMA) engine, a hardware accelerator, etc for performing sequences of processing operations. Program code defining the sequence of operations, and/or data required when performing such processing operations, will typically be stored within a memory of the data processing apparatus. The term “contents” will be used herein to collectively identify program code and/or data required when executing such code.
Where content needs to be protected, it is known to provide read only storage devices, for example Read Only Memory (ROM), or lockable FLASH devices, to store such data. With lockable devices such as a lockable FLASH device, the content that is required to be read only is stored within the FLASH device at initial program time, and thereafter a hardware mechanism is used to lock that content within the device so that it is from that point on only readable rather than writeable.
A typical example that uses such an approach is the storage of computer file systems, where the read only protection is controlled by the operating system under the assumption that the operating system is a trustable infrastructure.
Whilst such read only storage devices provide protection for the content, they are typically relatively slow to access, and this can significantly impact on the speed of operation of the data processing apparatus. Further, they lack flexibility with regard to how the content is accessed, since it is not possible to subsequently alter that content.
The above described approach relies on the read only nature of the memory device to provide protection to the content stored therein. As an alternative approach where quicker access to the content is required, it is known in relation to content required by a CPU to store that content in a writeable memory device, and then to use a Memory Management Unit (MMU) associated with the CPU to only allow certain portions of memory to be read but not written, this being defined by page tables accessible to the MMU. This process is controlled by the operating system, and hence again relies on the operating system being a trustable infrastructure.
It has typically been the job of the operating system developer to ensure that the operating system provides sufficient security to ensure that the secure data of one application cannot be accessed by other applications running under the control of the operating system. However, as systems become more complex, the general trend is for operating systems to become larger and more complex, and in such situations it becomes increasingly difficult to ensure sufficient security within the operating system itself. To seek to alleviate the reliance on operating system security, it is known to provide a system in which the data processing apparatus is provided with secure and non-secure domains, these domains providing a mechanism for handling security at the hardware level. Such a system is described for example in U.S. patent application Ser. No. 10/714,561, now U.S. Pat. No. 7,305,534, the contents of which are herein incorporated by reference. In such a system, the non-secure and secure domains in effect establish separate worlds, the secure domain providing a trusted execution space separated by hardware enforced boundaries from other execution spaces, and likewise the non-secure domain providing a non-trusted execution space.
Whilst such an approach enables secure content to be stored in a way where it can only be accessed by devices operating in the secure domain, there is still the problem that it may be necessary to provide access from the non-secure domain to certain non-secure content whilst ensuring that that content cannot be modified by applications running in the non-secure domain. Typically, it has only been possible to protect such content by storing that content in one of the earlier-described read only storage devices, for example one-time-programmable devices, or lockable memory devices like lockable FLASH devices. However, as mentioned earlier, this suffers from the performance problems and flexibility problems discussed earlier.